跳到主要内容

权限与审批

deny-first 分级模型、ML 分类器自动路由与审批疲劳的权衡

核心要点：

  • deny-first: deny → ask → allow 评估顺序
  • 多级权限模式覆盖不同信任度
  • 读免审，写/命令需确认且粒度可记忆
  • ML 分类器自动路由，reasoning-blind
  • 审批疲劳是安全剧场，要警惕

本文讲权限的人工审批交互。权限门作为技术隔离机制见 07-安全与沙箱/03-沙箱隔离。

agent 的权限怎么分级？​

核心问题：不能每个操作都问用户，也不能全放开，中间怎么分级？

用 deny-first 评估顺序 + 多级权限模式：默认拒绝，按信任度逐级放开[1]。Claude Code 的规则评估遵循 deny → ask → allow 顺序，先看是否命中拒绝规则，再看是否需询问，最后才允许。

权限模式提供多档信任（如 default / acceptEdits / plan / auto 等），跨多个配置层级，且高层的 managed settings 不可被低层覆盖。这套设计的可借鉴点：默认拒绝比默认允许安全——deny-first 让未明确授权的操作走人工确认，而非默默执行。

图 9.1: deny-first 权限评估流水线：工具调用依次匹配 deny、ask、allow 规则，未命中任何规则时走人工确认而非默默放行

审批粒度怎么定？​

核心问题：审批要细到每个操作，还是能批量记住？

按风险分级：读操作免审批，写/命令需确认，且可按粒度永久或会话级记忆[1]。粒度设计直接决定审批负担。

  • 读操作：免审批——读不改变状态，风险低。
  • Bash 命令：可按命令前缀永久记忆（批准一次某前缀，后续同前缀免问）。
  • 文件修改：通常仅 session 内有效，换会话重新确认。

可借鉴的判断：审批粒度要匹配风险与可逆性——低风险可逆操作放宽，高风险不可逆操作每次确认。这与 03-HITL与steering 的"不可逆操作强制 checkpoint"一致。

ML 分类器怎么减审批疲劳？​

核心问题：操作一多，用户被问到麻木，怎么自动化又不失控？

用 ML 分类器自动路由每次工具调用，且故意不读 agent 的内部推理(reasoning-blind)[2]。Claude Code 的 auto 模式以四层优先级（hard_deny / soft_deny / allow / 显式用户意图）分两阶段（快速过滤 + 深度推理）路由[1]。

reasoning-blind 是关键安全设计：分类器不看 agent 的推理 token，防止被恶意 agent 用"看似合理的解释"操纵。这呼应了 07-安全与沙箱/02-prompt-injection 的信任边界思路——审批决策不能信任被审批方的自述。可借鉴的设计：自动审批要独立于 agent 的自我说明，基于操作本身判断。

审批疲劳为什么危险？​

核心问题：把审批做顺手了，有什么隐患？

审批疲劳会让审批退化成"安全剧场"——危险操作混进例行噪音被一并放过。当大部分请求在自动驾驶下被批准，用户对审批提示麻木，真正危险的操作就容易蒙混过关。

短时间内异常多的审批或拒绝请求本身也可作为可疑信号：auto 模式在累计多次拒绝后会升级到人工[1]。可借鉴的原则：审批的价值在于稀缺——把例行操作自动化、只对真正高风险的操作打断用户，比"什么都问"更安全，因为后者训练用户无脑点同意。

Takeaway​

知识点核心结论
deny-firstdeny → ask → allow，默认拒绝比默认允许安全
权限模式多档信任 + 多层配置，高层不可被低层覆盖
审批粒度读免审、命令前缀可记忆、写改会话级，匹配风险与可逆性
ML 分类器自动路由 + reasoning-blind，不信任被审批方自述
审批疲劳万事皆问=安全剧场，只打断高风险操作

参考资料​

  1. Anthropic. Claude Code: Configure permissions / Configure auto mode. 2025. https://code.claude.com/docs/en/permissions / https://code.claude.com/docs/en/auto-mode-config
  2. Liu et al. Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems. arXiv:2604.14228, 2026. https://arxiv.org/abs/2604.14228

延伸阅读​